Method and apparatus for delaying interfering accesses from other threads during transactional program execution

ABSTRACT

One embodiment of the present invention provides a system that facilitates delaying interfering memory accesses from other threads during transactional execution. During transactional execution of a block of instructions, the system receives a request from another thread (or processor) to perform a memory access involving a cache line. If performing the memory access on the cache line will interfere with the transactional execution and if it is possible to delay the memory access, the system delays the memory access and stores copy-back information for the cache line to enable the cache line to be copied back to the requesting thread. At a later time, when the memory access will no longer interfere with the transactional execution, the system performs the memory access and copies the cache line back to the requesting thread.

RELATED APPLICATION

This application hereby claims priority under 35 U.S.C. §119 to U.S.Provisional Patent Application No. 60/447,128, filed on 13 Feb. 2003,entitled “Transactional Memory,” by inventors Shailender Chaudhry, MarcTremblay and Quinn Jacobson (Attorney Docket No. SUN-P9322PSP).

BACKGROUND

1. Field of the Invention

The present invention relates to techniques for improving theperformance of computer systems. More specifically, the presentinvention relates to a method and an apparatus for delaying memoryaccesses from other threads that interfere with on-going transactionalprogram execution.

2. Related Art

Computer system designers are presently developing mechanisms to supportmulti-threading within the latest generation of Chip-Multiprocessors(CMPs) as well as more traditional Shared Memory Multiprocessors (SMPs).With proper hardware support, multi-threading can dramatically increasethe performance of numerous applications. However, as microprocessorperformance continues to increase, the time spent synchronizing betweenthreads (processes) is becoming a large fraction of overall executiontime. In fact, as multi-threaded applications begin to use even morethreads, this synchronization overhead becomes the dominant factor inlimiting application performance.

From a programmer's perspective, synchronization is generallyaccomplished through the use locks. A lock is typically acquired beforea thread enters a critical section of code, and is released after thethread exits the critical section. If another thread wants to enter thesame critical section, it must acquire the same lock. If it is unable toacquire the lock, because a preceding thread has grabbed the lock, thethread must wait until the preceding thread releases the lock. (Notethat a lock can be implemented in a number of ways, such as throughatomic operations or semaphores.)

Unfortunately, the process of acquiring a lock and the process ofreleasing a lock are very time-consuming in modern microprocessors. Theyinvolve atomic operations, which typically flush the load buffer andstore buffer, and can consequently require hundreds, if not thousands,of processor cycles to complete.

Moreover, as multi-threaded applications use more threads, more locksare required. For example, if multiple threads need to access a shareddata structure, it is impractical for performance reasons to use asingle lock for the entire data structure. Instead, it is preferable touse multiple fine-grained locks to lock small portions of the datastructure. This allows multiple threads to operate on different portionsof the data structure in parallel. However, it also requires a singlethread to acquire and release multiple locks in order to accessdifferent portions of the data structure.

In some cases, locks are used when they are not required. For example,many applications make use of “thread-safe” library routines that uselocks to ensure that they are “thread-safe” for multi-threadedapplications. Unfortunately, the overhead involved in acquiring andreleasing these locks is still incurred, even when the thread-safelibrary routines are called by a single-threaded application.

Applications typically use locks to ensure mutual exclusion withincritical sections of code. However, in many cases threads will notinterfere with each other, even if they are allowed to execute acritical section simultaneously. In these cases, mutual exclusion isused to prevent the unlikely case in which threads actually interferewith each other. Consequently, in these cases, the overhead involved inacquiring and releasing locks is largely wasted.

Hence, what is needed is a method and an apparatus that reduces theoverhead involved in manipulating locks when accessing criticalsections.

One technique to reduce the overhead involved in manipulating locks isto “transactionally” execute a critical section, wherein changes madeduring the transactional execution are not committed to thearchitectural state of the processor until the transactional executionsuccessfully completes. This technique is described in related U.S.patent application Ser. No. 10/637,168, entitled, “SelectivelyMonitoring Loads to Support Transactional Program Execution,” byinventors Marc Tremblay, Quinn A. Jacobson and Shailender Chaudhry,filed on 8 Aug. 2003 (Attorney Docket No. SUN-P9327-MEG).

During transactional execution, load and store operations are modifiedso that they mark cache lines that are accessed during the transactionalexecution. This allows the computer system to determine if aninterfering data access occurs during the transactional execution. Ifso, the transactional execution fails, and results of the transactionalexecution are not committed to the architectural state of the processor.One the other hand, if the transactional execution successfully executesa block of instructions, results of the transactional execution areatomically committed to the architectural state of the processor.

Unfortunately, this commit operation does not happen instantaneously.During the commit operation, stores that took place during transactionalexecution must somehow be committed to the architectural state of theprocessor. Note that there can potentially be a large number of stores,so committing these stores can take a significant amount of time. Whilethe stores are being committed, an interfering data access from anotherthread can potentially occur. However, failing the transactionalexecution to deal with this type of interfering data access during thecommit operation is not a viable option, because doing so can leave theprocessor in an inconsistent state, with only a portion of thetransactional updates committed.

Hence, what is needed is a method and an apparatus for preventingaccesses from other threads from interfering with transactional programexecution, and in particular that prevents accesses from other threadsfrom interfering with a commit operation that takes place at the end oftransactional program execution.

SUMMARY

One embodiment of the present invention provides a system thatfacilitates delaying interfering memory accesses from other threadsduring transactional execution. During transactional execution of ablock of instructions, the system receives a request from another thread(or processor) to perform a memory access involving a cache line. Ifperforming the memory access on the cache line will interfere with thetransactional execution and if it is possible to delay the memoryaccess, the system delays the memory access and stores copy-backinformation for the cache line to enable the cache line to be copiedback to the requesting thread. At a later time, when the memory accesswill no longer interfere with the transactional execution, the systemperforms the memory access and copies the cache line back to therequesting thread.

In a variation on this embodiment, it is possible to delay aninterfering memory access if a commit operation is in the process ofcommitting updates made during the transactional execution to thearchitectural state of the processor, and if the memory access isdirected to a cache line for which a last update made during thetransactional execution has not yet been committed to the architecturalstate of the processor.

In a further variation, a cache line associated with a delayed memoryaccess is copied back to the requesting thread after the last update tothe cache line during the transactional execution is committed to thearchitectural state of the processor.

In a variation on this embodiment, the cache line associated with adelayed memory access is copied back to the requesting thread after allupdates that took place during the transactional execution are committedto the architectural state of the processor.

In a variation on this embodiment, it is possible to delay aninterfering memory access prior to the commit operation. In this case,if the transactional execution fails prior to the commit operation, thesystem copies back cache lines for any interfering memory accesses thathave been delayed during the transactional execution, wherein the datathat is copied back is original cache line data, which has not beenmodified during the transactional execution.

In a variation on this embodiment, if the memory access will interferewith the transactional execution and if it is not possible to delay thememory access, the system discards changes made during the transactionalexecution. The system also allows the memory access to complete andattempts to re-execute the block of instructions.

In a further variation, discarding changes made during transactionalexecution involves: discarding register file changes made during thetransactional execution; clearing load marks from cache lines; drainingstore buffer entries generated during the transactional execution; andclearing store marks from cache lines.

In a variation on this embodiment, an interfering memory access caninclude: a store by another thread to a cache line that has beenload-marked by the thread; and a load or a store by another thread to acache line that has been store-marked by the thread.

In a variation on this embodiment, commencing transactional executioninvolves: saving processor registers; configuring the processor toload-mark cache lines during loads that take place during transactionalexecution; configuring the processor to store-mark cache lines duringstores that take place during transactional execution; and configuringthe processor to continually monitor data references from other threadsto detect interfering data references.

In a variation on this embodiment, if transactional execution completeswithout encountering an interfering memory access from another thread,the system commits changes made during the transactional execution tothe architectural state of the processor, and resumes normalnon-transactional execution of the program past the block ofinstructions.

In a further variation, committing changes made during transactionalexecution involves: clearing load marks from cache lines; committingregister file changes made during transactional execution; andcommitting store buffer entries generated during the transactionalexecution to memory. Note that if a store buffer entry contains a lastupdate made to a cache line made during the transactional execution,committing the store buffer entry can involve unmarking thecorresponding cache line.

In a variation on this embodiment, the request to perform the memoryaccess can include a request-to-own (RTO) signal or a request-to-share(RTS) signal.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a computer system in accordance with an embodiment ofthe present invention.

FIG. 2 illustrates how a critical section is executed in accordance withan embodiment of the present invention.

FIG. 3 presents a flow chart illustrating the transactional executionprocess in accordance with an embodiment of the present invention.

FIG. 4 presents a flow chart illustrating a start transactionalexecution (STE) operation in accordance with an embodiment of thepresent invention.

FIG. 5 presents a flow chart illustrating how load-marking is performedduring transactional execution in accordance with an embodiment of thepresent invention.

FIG. 6 presents a flow chart illustrating how store-marking is performedduring transactional execution in accordance with an embodiment of thepresent invention.

FIG. 7 presents a flow chart illustrating how a commit operation isperformed in accordance with an embodiment of the present invention.

FIG. 8 presents a flow chart illustrating how changes are discardedafter transactional execution completes unsuccessfully in accordancewith an embodiment of the present invention.

FIG. 9A presents a flow chart illustrating how monitored and unmonitoredload instructions are generated in accordance with an embodiment of thepresent invention.

FIG. 9B presents a flow chart illustrating how monitored and unmonitoredload instructions are executed in accordance with an embodiment of thepresent invention.

FIG. 10A presents a flow chart illustrating how monitored andunmonitored store instructions are generated in accordance with anembodiment of the present invention.

FIG. 10B presents a flow chart illustrating how monitored andunmonitored store instructions are executed in accordance with anembodiment of the present invention.

FIG. 11 presents a timeline illustrating transactional program executionin accordance with an embodiment of the present invention.

FIG. 12 illustrates various items of state information associated withan L2 cache line in accordance with an embodiment of the presentinvention.

FIG. 13 presents a flow chart illustrating how interfering accesses aredelayed during transactional program execution in accordance with anembodiment of the present invention.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the invention, and is provided in the context ofa particular application and its requirements. Various modifications tothe disclosed embodiments will be readily apparent to those skilled inthe art, and the general principles defined herein may be applied toother embodiments and applications without departing from the spirit andscope of the present invention. Thus, the present invention is notintended to be limited to the embodiments shown, but is to be accordedthe widest scope consistent with the principles and features disclosedherein.

The data structures and code described in this detailed description aretypically stored on a computer readable storage medium, which may be anydevice or medium that can store code and/or data for use by a computersystem. This includes, but is not limited to, magnetic and opticalstorage devices such as disk drives, magnetic tape, CDs (compact discs)and DVDs (digital versatile discs or digital video discs), and computerinstruction signals embodied in a transmission medium (with or without acarrier wave upon which the signals are modulated). For example, thetransmission medium may include a communications network, such as theInternet.

Computer System

FIG. 1 illustrates a computer system 100 in accordance with anembodiment of the present invention. Computer system 100 can generallyinclude any type of computer system, including, but not limited to, acomputer system based on a microprocessor, a mainframe computer, adigital signal processor, a portable computing device, a personalorganizer, a device controller, and a computational engine within anappliance. As is illustrated in FIG. 1, computer system 100 includesprocessors 101 and level 2 (L2) cache 120, which is coupled to mainmemory (not shown). Processor 102 is similar in structure to processor101, so only processor 101 is described below.

Processor 101 has two register files 103 and 104, one of which is an“active register file” and the other of which is a backup “shadowregister file.” In one embodiment of the present invention, processor101 provides a flash copy operation that instantly copies all of thevalues from register file 103 into register file 104. This facilitates arapid register checkpointing operation to support transactionalexecution.

Processor 101 also includes one or more functional units, such as adder107 and multiplier 108. These functional units are used in performingcomputational operations involving operands retrieved from registerfiles 103 or 104. As in a conventional processor, load and storeoperations pass through load buffer 111 and store buffer 112.

Processor 101 additionally includes a level one (L1) data cache 115,which stores data items that are likely to be used by processor 101.Note that each line in L1 data cache 115 includes a “load-marking bit,”which indicates that a data value from the line has been loaded duringtransactional execution. This load-marking bit is used to determinewhether any interfering memory references take place duringtransactional execution as is described below with reference to FIGS.3-8. Processor 101 also includes an L1 instruction cache (not shown).

Note that load-marking does not necessarily have to take place in L1data cache 115. In general load-marking can take place at any levelcache, such as L2 cache 120, or even in an independent structure.However, for performance reasons, the load-marking will likely takeplace at the cache level that is as close to the processor as possible,which in this case is L1 data cache 115. Otherwise, loads would have togo to L2 cache 120 even on an L1 hit.

L2 cache 120 operates in concert with L1 data cache 115 (and acorresponding L1 instruction cache) in processor 101, and with L1 datacache 117 (and a corresponding L1 instruction cache) in processor 102.Note that L2 cache 120 is associated with a coherency mechanism 122,such as the reverse directory structure described in U.S. patentapplication Ser. No. 10/186,118, entitled, “Method and Apparatus forFacilitating Speculative Loads in a Multiprocessor System,” filed onJun. 26, 2002, by inventors Shailender Chaudhry and Marc Tremblay(Publication No. US-2002-0199066-A1). This coherency mechanism 122maintains “copyback information” 121 for each cache line. This copybackinformation 121 facilitates sending a cache line from L2 cache 120 to arequesting processor in cases where a cache line must be sent to anotherprocessor.

Each line in L2 cache 120 includes a “store-marking bit,” whichindicates that a data value has been stored to the line duringtransactional execution. This store-marking bit is used to determinewhether any interfering memory references take place duringtransactional execution as is described below with reference to FIGS.3-8. Note that store-marking does not necessarily have to take place inL2 cache 120.

Ideally, the store-marking takes place in the cache level closest to theprocessor where cache lines are coherent. For write-through L1 datacaches, writes are automatically propagated to L2 cache 120. However, ifan L1 data cache is a write-back cache, we perform store-marking in theL1 data cache. (Note that the cache coherence protocol ensures that anyother processor that subsequently modifies the same cache line willretrieve the cache line from the L1 cache, and will hence become awareof the store-mark.)

Executing a Critical Section

FIG. 2 illustrates how a critical section is executed in accordance withan embodiment of the present invention. As is illustrated in theleft-hand side of FIG. 2, a thread that executes a critical sectiontypically acquires a lock associated with the critical section beforeentering the critical section. If the lock has been acquired by anotherthread, the thread may have to wait until the other thread releases thelock. Upon leaving the critical section, the thread releases the lock.(Note that the terms “thread” and “process” are used interchangeablythroughout this specification.)

A lock can be associated with a shared data structure. For example,before accessing a shared data structure, a thread can acquire a lock onthe shared data structure. The thread can then execute a criticalsection of code that accesses the shared data structure. After thethread is finished accessing the shared data structure, the threadreleases the lock.

In contrast, in the present invention, the thread does not acquire alock, but instead executes a start transactional execution (STE)instruction before entering the critical section. If the criticalsection is successfully completed without interference from otherthreads, the thread performs a commit operation, to commit changes madeduring transactional execution. This sequence of events is described inmore detail below with reference to FIGS. 3-8.

Note that in one embodiment of the present invention a compiler replaceslock-acquiring instructions with STE instructions, and also replacescorresponding lock releasing instructions with commit instructions.(Note that there may not be a one-to-one correspondence between replacedinstructions. For example, a single lock acquisition operation comprisedof multiple instructions may be replaced by a single STE instruction.)The above discussion presumes that the processor's instruction set hasbeen augmented to include an STE instruction and a commit instruction.These instructions are described in more detail below with reference toFIGS. 3-9.

Transactional Execution Process

FIG. 3 presents a flow chart illustrating how transactional executiontakes place in accordance with an embodiment of the present invention. Athread first executes an STE instruction prior to entering of a criticalsection of code (step 302). Next, the system transactionally executescode within the critical section, without committing results of thetransactional execution (step 304).

During this transactional execution, the system continually monitorsdata references made by other threads, and determines if an interferingdata access (or other type of failure) takes place during transactionalexecution. If not, the system atomically commits all changes made duringtransactional execution (step 308) and then resumes normalnon-transactional execution of the program past the critical section(step 310).

On the other hand, if an interfering data access is detected, the systemdiscards changes made during the transactional execution (step 312), andattempts to re-execute the critical section (step 314).

In one embodiment of the present invention, the system attempts thetransactionally re-execute the critical section zero, one, two or moretimes. If these attempts are not successful, the system executes analternative block of code in normal execution mode. This alternativecode may perform additional attempts to perform the transaction and willlikely have the ability to reverts back to the conventional technique ofacquiring a lock on the critical section before entering the criticalsection, and then releasing the lock after leaving the critical section.

Note that an interfering data access can include a store by anotherthread to a cache line that has been load-marked by the thread. It canalso include a load or a store by another thread to a cache line thathas been store-marked by the thread.

Also note that circuitry to detect interfering data accesses can beeasily implemented by making minor modifications to conventional cachecoherence circuitry. This conventional cache coherence circuitrypresently generates signals indicating whether a given cache line hasbeen accessed by another processor. Hence, these signals can be used todetermine whether an interfering data access has taken place.

Starting Transactional Execution

FIG. 4 presents a flow chart illustrating a start transactionalexecution (STE) operation in accordance with an embodiment of thepresent invention. This flow chart illustrates what takes place duringstep 302 of the flow chart in FIG. 3. The system starts by checkpointingthe register file (step 402). This can involve performing a flash copyoperation from register file 103 to register file 104 (see FIG. 1). Inaddition to checkpointing register values, this flash copy can alsocheckpoint various state registers associated with the currentlyexecuting thread. In general, the flash copy operation checkpointsenough state to be able to restart the corresponding thread.

At the same time the register file is checkpointed, the STE operationalso causes store buffer 112 to become “gated” (step 404). This allowsexisting entries in store buffer to propagate to the memory sub-system,but prevents new store buffer entries generated during transactionalexecution from doing so.

The system then starts transactional execution (step 406), whichinvolves load-marking and store-marking cache lines, if necessary, aswell as monitoring data references in order to detect interferingreferences.

Load-Marking Process

FIG. 5 presents a flow chart illustrating how load-marking is performedduring transactional execution in accordance with an embodiment of thepresent invention. During transactional execution of a critical section,the system performs a load operation. In performing this load operationif the load operation has been identified as a load operation that needsto be load-marked, system first attempts to load a data item from L1data cache 115 (step 502). If the load causes a cache hit, the system“load-marks” the corresponding cache line in L1 data cache 115 (step506). This involves setting the load-marking bit for the cache line.Otherwise, if the load causes a cache miss, the system retrieves thecache line from further levels of the memory hierarchy (step 508), andproceeds to step 506 to load-mark the cache line in L1 data cache 115.

Store-Marking Process

FIG. 6 presents a flow chart illustrating how store-marking is performedduring transactional execution in accordance with an embodiment of thepresent invention. During transactional execution of a critical section,the system performs a store operation. If this store operation has beenidentified as a store operation that needs to be store-marked, thesystem first prefetches a corresponding cache line for exclusive use(step 602). Note that this prefetch operation will do nothing if theline is already located in cache and is already in an exclusive usestate.

Since in this example L1 data cache 115 is a write-through cache, thestore operation propagates through L1 data cache 115 to L2 cache 120.The system then attempts to lock the cache line corresponding to thestore operation in L2 data cache 115 (step 604). If the correspondingline is in L2 cache 120 (cache hit), the system “store-marks” thecorresponding cache line in L2 cache 120 (step 610). This involvessetting the store-marking bit for the cache line. Otherwise, if thecorresponding line is not in L2 cache 120 (cache miss), the systemretrieves the cache line from further levels of the memory hierarchy(step 608) and then proceeds to step 610 to store-mark the cache line inL2 cache 120.

Next, after the cache line is store-marked in step 610, the systementers the store data into an entry of the store buffer 112 (step 612).Note that this store data will remain in store buffer 112 until asubsequent commit operation takes place, or until changes made duringthe transactional execution are discarded.

Note that a cache line that is store marked by a given thread can beread by other threads. Note that this may cause the given thread to failwhile the other threads continue.

Commit Operation

FIG. 7 presents a flow chart illustrating how a commit operation isperformed after transactional execution completes successfully inaccordance with an embodiment of the present invention. This flow chartillustrates what takes place during step 308 of the flow chart in FIG.3.

The system starts by treating store-marked cache lines as though theyare locked (step 702). This means other threads that request astore-marked line must wait until the line is no longer locked beforethey can access the line. This is similar to how lines are locked inconventional caches.

Next, the system clears load-marks from L1 data cache 115 (step 704).

The system then commits entries from store buffer 112 for stores thatare identified as needing to be marked, which were generated during thetransactional execution, into the memory hierarchy (step 706). As eachentry is committed, a corresponding line in L2 cache 120 is unlocked.

The system also commits register file changes (step 708). For example,this can involve functionally performing a flash copy between registerfile 103 and register file 104 in the system illustrated in FIG. 1.

Discarding Changes

FIG. 8 presents a flow chart illustrating how changes are discardedafter transactional execution completes unsuccessfully in accordancewith an embodiment of the present invention. This flow chart illustrateswhat takes place during step 312 of the flow chart in FIG. 3. The systemfirst discards register file changes made during the transactionalexecution (step 802). This can involve either clearing or simplyignoring register file changes made during transactional execution. Thisis easy to accomplish because the old register values were checkpointedprior to commencing transactional execution. The system also clearsload-marks from cache lines in L1 data cache 115 (step 804), and drainsstore buffer entries generated during transactional execution withoutcommitting them to the memory hierarchy (step 806). At the same time,the system unmarks corresponding L2 cache lines. Finally, in oneembodiment of the present invention, the system branches to a targetlocation specified by the STE instruction (step 808). The code at thistarget location attempts to re-execute the critical section as isdescribed above with reference to step 314 of FIG. 1.

Monitored Load Instructions

FIG. 9A presents a flow chart illustrating how monitored and unmonitoredload instructions are generated in accordance with an embodiment of thepresent invention. This process takes place when a program is beinggenerated to support transactional execution. For example, in oneembodiment of the present invention, a compiler or virtual machineautomatically generates native code to support transactional execution.In another embodiment, a programmer manually generates code to supporttransactional execution.

The system first determines whether a given load operation within ablock of instructions to be transactionally executed needs to bemonitored (step 902). In one embodiment of the present invention, thesystem determines whether a load operation needs to be monitored bydetermining whether the load operation is directed to a heap. Note thata heap contains data that can potentially be accessed by other threads.Hence, loads from the heap need to be monitored to detect interference.In contrast, loads from outside the heap, (for example, from the localstack) are not directed to data that is shared by other threads, andhence do not need to be monitored to detect interference.

One embodiment of the present invention determines whether a loadoperation needs to be monitored at the programming-language level, byexamining a data structure associated with the load operation todetermine whether the data structure is a “protected” data structure forwhich loads need to be monitored, or an “unprotected” data structure forwhich loads do not need to be monitored.

In yet another embodiment, the system allows a programmer to determinewhether a load operation needs to be monitored.

If the system determines that a given load operation needs to bemonitored, the system generates a “monitored load” instruction (step904). Otherwise, the system generates an “unmonitored load” instruction(step 906).

There are a number of different ways to differentiate a monitored loadinstruction from an unmonitored load instruction. (1) The system can usethe op code to differentiate a monitored load instruction from anunmonitored load instruction. (2) Alternatively, the system can use theaddress of the load instruction to differentiate between the two typesof instructions. For example, loads directed to a certain range ofaddresses can be monitored load instructions, whereas loads directed toother address can be unmonitored load instructions.

Also note that an unmonitored load instruction can either indicate thatno other thread can possibly interfere with the load operation, or itcan indicate that interference is possible, but it is not a reason tofail. (Note that in some situations, interfering accesses to shared datacan be tolerated.)

FIG. 9B presents a flow chart illustrating how monitored and unmonitoredload instructions are executed in accordance with an embodiment of thepresent invention. The system first determines whether the loadinstruction is a monitored load instruction or an unmonitored loadinstruction (step 910). This can be accomplished by looking at the opcode of the load instruction, or alternatively, looking at the addressfor the load instruction. Note that the address can be examined bycomparing the address against boundary registers, or possibly examininga translation lookaside buffer (TLB) entry fro the address to determineif the address falls within a monitored range of addresses.

If the load instruction is a monitored load instruction, the systemperforms the corresponding load operation and load marks the associatedcache line (step 914). Otherwise, if the load instruction is anunmonitored load instruction, the system performs the load operationwithout load-marking the cache line (step 916).

In a variant of the embodiment of the present invention, the system doesnot allow an unmarked load operation from the current thread cause otherthreads to fail transactional execution. This can be accomplished bypropagating additional information during the coherency transactionsassociated with the load operation to ensure that the load operationdoes not cause another thread to fail.

Monitored Store Instructions

FIG. 10A presents a flow chart illustrating how monitored andunmonitored store instructions are generated in accordance with anembodiment of the present invention. As was described above for loadoperations, this process can take place when a compiler or virtualmachine automatically generates native code to support transactionalexecution, or when a programmer manually generates code to supporttransactional execution.

The system first determines whether a store operation within a block ofinstructions to be transactionally executed needs to be monitored (step1002). This determination can be made in the based on the same factorsas for load instructions.

If the system determines that a store operation needs to be monitored,the system generates a “monitored store” instruction (step 1004).Otherwise, the system generates an “unmonitored store” instruction (step1006).

Note that monitored store instructions can be differentiated fromunmonitored store instructions in the same way that monitored loadinstructions can be differentiated from unmonitored load instructions,for example the system can use different op codes or different addressranges.

FIG. 10B presents a flow chart illustrating how monitored andunmonitored store instructions are executed in accordance with anembodiment of the present invention. The system first determines whetherthe store instruction is a monitored store instruction or an unmonitoredstore instruction (step 1010). This can be accomplished by looking atthe op code for the store instruction, or alternatively, looking at theaddress for the store instruction. If the store instruction is amonitored store instruction, the system performs the corresponding storeoperation to a gated store buffer, or in another way so that it can belater undone, and store marks the associated cache line (step 1014).Otherwise, if the store instruction is an unmonitored store instruction,the system performs the store operation without store-marking the cacheline (step 1016).

Note that a store-marked cache line can indicate one or more of thefollowing: (1) loads from other threads to the cache line should bemonitored; (2) stores from other threads to the cache line should bemonitored; or (3) stores to the cache line should be buffered until thetransactional execution completes.

In a variant of the embodiment of the present invention, the system doesnot allow an unmarked store operation from the current thread causeanother thread to fail transactional execution. This can be accomplishedby propagating additional information during coherency transactionsassociated with the store operation to ensure that the store operationdoes not cause another thread to fail.

Delaying Interfering Accesses

FIG. 11 presents a timeline illustrating transactional program executionin accordance with an embodiment of the present invention. At thebeginning of transactional program execution, a checkpoint operation1102 takes place. This enables the system to return to the checkpoint ifa failure subsequently occurs during transactional execution. Duringtransactional execution, a number of load and store operations areperformed, which cause corresponding cache lines to be marked. (Notethat only the store operations are illustrated in FIG. 11.) At the endof transactional execution, a commit operation takes place, whichcommits changes made during the speculative execution to thearchitectural state of the processor. In one embodiment of the presentinvention, this involves committing entries from a store buffer into theL2 cache. Finally, after all changes made during the transactionalexecution are committed to the architectural state of the processor, thecommit operation is complete, and normal, non-speculative programexecution resumes.

Note that during a problem window 1104 results of the transactionalexecution are being committed to the architectural state of theprocessor. During this problem window, interfering accesses from otherthreads can potentially occur. However, failing transactional executionwithin problem window 1104 to deal with an interfering access can causeproblems. In particular, if the commit operation is only partiallycomplete, it is possible to leave the processor in an inconsistentstate, with only a portion of the transactional updates committed. Oneway to solve this problem is to delay interfering data accesses untilthe commit operation completes. This delaying technique is described inmore detail below with reference to FIGS. 12-13. (Note that aninterfering access from another process can include a cache-coherencesignal, such as a request-to-own (RTO) signal or a request-to-share(RTS) signal.)

State Information

FIG. 12 illustrates various items of state information associated withan L2 cache line in accordance with an embodiment of the presentinvention. Much of this state information is standard for cache lines ina cache-coherent computer system. In particular, the cache lineillustrated in FIG. 12 includes data 1218 and address tag field 1201, aswell as state bits associated with cache coherence operations, includingvalid bit 1204, dirty bit 1206 and owned bit 1208.

In addition to this standard state information, the system maintains astore-mark bit 1210, which indicates that the cache line was written toduring transactional execution, and that at least one correspondingstore buffer entry is waiting to be committed to the cache line. Thesystem also maintains a locked bit 1212, which indicates that the cacheline is to remain locked in cache during the commit operation until thecorresponding store buffer entry (or entries) are committed to the cacheline. (Note that it may be possible to combine store-mark bit 1210 andlocked bit 1212 into a single same bit.) In one embodiment of thepresent invention, the system also maintains a thread ID 1211, whichindicates which thread has locked (or has store-marked) the cache line.

The system can also maintain copy-back information for the cache line,including a “to be copied back bit” 1214, which indicates whether thecache line has to be copied back to another thread. It also includes acopy back list 1216, which identifies where the cache line has to becopied back to. In one embodiment of the present invention, copy-backlist 1216 is a one-hot bit vector, wherein each bit indicates whetherthe cache line has to be copied back to a specific thread (orprocessor).

Note that there are many alternative ways to encode the stateinformation illustrated in FIG. 12. For example, in one embodiment ofthe present invention, the system encodes the state informationillustrated in FIG. 12 using a more dense encoding into fewer bits.

Process of Delaying an Interfering Access

FIG. 13 presents a flow chart illustrating how interfering accesses aredelayed during transactional program execution in accordance with anembodiment of the present invention. During operation, the systemobtains ownership of a cache line in L2 cache 120 (step 1302). Sharedownership is sufficient for cache lines that are only read whileexclusive ownership is necessary for caches lines stored to. Next,during subsequent transactional program execution, the system load-markscache lines in L1 cache and store marks cache lines in L2 cache asdescribed above (step 1304).

If an interfering access from another process is encountered duringtransactional execution, the system fails the transaction as describedabove and possibly gives up ownership of the cache line (step 1306). Thesystem then returns to step 1304 and attempts to repeat the failedtransactional execution.

In an alternative embodiment of the present invention (indicated by thedashed line), instead of failing the transaction, the system delays theinterfering access and stores copy back information to enable theinterfering access to complete at a later time (step 1308). Note that ifthe interfering access is a store to a load-marked cache line, theinterfering access can complete as soon as the commit operation begins,without having to wait for stores to be committed to the architecturalstate of the processor. Otherwise, in the case of a load or a store to astore-marked cache line, the system has to wait until after the lastupdate to the cache line during the transactional execution is committedto the architectural state of the processor before completing theinterfering access. (Note that a load from a load-marked cache line doesnot interfere with transactional program execution.)

In this alternative embodiment, if transactional execution for somereason fails, the system copies back cache lines for any interferingaccesses that have been delayed during transactional execution (step1305). In doing so, the system copies back original cache line data,which has not been modified during the transactional execution. Next,the system returns to step 1304 and attempts to repeat the filedtransactional execution.

After transactional execution completes, the system performs a commitoperation (step 1309). During this commit operation, stores that tookplace during transactional execution are drained from the store bufferto the L2 cache (which represents the architectural state of theprocessor). If an interfering access from another process is encounteredduring the commit operation, the system delays the interfering accessand stores copy back information to enable the interfering access tocomplete at a later time (step 1310). (While delaying this access, thesystem can possibly acknowledge ownership of the cache line as part of acache coherence protocol and can delay performing a copy-back operation,or equivalent operation that gives up ownership, for the cache line.)The system then returns to step 1309 to complete the commit operation.

After all stores are all committed, the system can complete all delayedaccesses and can perform copy-back operations as necessary (step 1312).The system can also give up ownership of the corresponding cache linesif necessary. Next, the system then returns to normal non-transactionalexecution (step 1314).

Note that it is not necessary to wait until all stores are committedbefore performing the copy-back operations, or equivalent operationsthat gives up ownership,. In one embodiment of the present invention, agiven cache line is copied back to requesting threads after the lastupdate to the given cache line that took place during the transactionalexecution is committed to the architectural state of the processor.

The foregoing descriptions of embodiments of the present invention havebeen presented for purposes of illustration and description only. Theyare not intended to be exhaustive or to limit the present invention tothe forms disclosed. Accordingly, many modifications and variations willbe apparent to practitioners skilled in the art. Additionally, the abovedisclosure is not intended to limit the present invention. The scope ofthe present invention is defined by the appended claims.

1-25. (canceled)
 26. An apparatus that facilitates delaying memoryaccesses directed to cache lines associated with transactionalexecution, comprising: a transactional execution mechanism configured tocommence transactional execution of a block of instructions within athread executing on a processor; and a request processing mechanismconfigured to receive a request from a requesting thread to perform amemory access involving a cache line; wherein if performing the memoryaccess on the cache line will interfere with the transactional executionand if it is possible to delay the memory access, the request processingmechanism is configured to perform the memory access at a later timewhen the memory access will not interfere with the transaction.
 27. Theapparatus of claim 26, wherein while performing the memory access at alater time when the memory access will not interfere with thetransaction, the request processing mechanism is configured to: storecopy-back information for the cache line to enable the cache line to becopied back to the requesting thread, and to perform the memory accessand copy the cache line back to the requesting thread at a later timewhen the memory access will not interfere with the transactionalexecution.
 28. The apparatus of claim 26, wherein performing the memoryaccess involves copying the cache line back to the requesting thread.29. The apparatus of claim 26, wherein it is possible to delay aninterfering memory access if a commit operation is in the process ofcommitting updates made during the transactional execution to thearchitectural state of the processor, and if the memory access isdirected to a cache line for which a last update made during thetransactional execution has not yet been committed to the architecturalstate of the processor.
 30. The apparatus of claim 29, wherein therequest processing mechanism is configured to copy back a cache lineassociated with a delayed memory access to the requesting thread afterthe last update to the cache line during the transactional execution iscommitted to the architectural state of the processor.
 31. The apparatusof claim 29, wherein the request processing mechanism is configured tocopy back a cache line associated with a delayed memory access to therequesting thread after all updates that took place during thetransactional execution are committed to the architectural state of theprocessor.
 32. The apparatus of claim 29, wherein it is possible todelay an interfering memory access prior to the commit operation; andwherein if the transactional execution fails prior to the commitoperation, the request processing mechanism is configured to copy backcache lines for any interfering memory accesses that have been delayedduring the transactional execution, wherein the data that is copied backis original cache line data, which has not been modified during thetransactional execution.
 33. The apparatus of claim 26, wherein if thememory access will interfere with the transactional execution and if itis not possible to delay the memory access, the transactional executionmechanism is configured to: discard changes made during thetransactional execution; allow the memory access to complete; and toattempt to re-execute the block of instructions.
 34. The apparatus ofclaim 33, wherein while discarding changes made during the transactionalexecution, the transactional execution mechanism is configured to:discard register file changes made during the transactional execution;clear load marks from cache lines; drain store buffer entries generatedduring the transactional execution; and to clear store marks from cachelines.
 35. The apparatus of claim 26, wherein an interfering memoryaccess can include: a store by another thread to a cache line that hasbeen load-marked by the thread; and a load or a store by another threadto a cache line that has been store-marked by the thread.
 36. Theapparatus of claim 26, wherein while commencing transactional execution,the transactional execution mechanism is configured to: save processorregisters; configure the processor to load-mark cache lines during loadsthat take place during transactional execution; configure the processorto store-mark cache lines during stores that take place duringtransactional execution; and to configure the processor to continuallymonitor data references from other threads to detect interfering datareferences.
 37. The apparatus of claim 26, wherein if transactionalexecution completes without encountering an interfering memory accessfrom another thread, the transactional processing mechanism isconfigured to: commit changes made during the transactional execution tothe architectural state of the processor; and to resume normalnon-transactional execution of the program past the block ofinstructions.
 38. The apparatus of claim 37, wherein while committingchanges made during transactional execution, the transactionalprocessing mechanism is configured to: clear load marks from cachelines; commit store buffer entries generated during the transactionalexecution to memory, wherein if a store buffer entry contains a lastupdate made to a cache line during the transactional execution,committing the store buffer entry involves unmarking the correspondingcache line; and to commit register file changes made duringtransactional execution.
 39. The apparatus of claim 26, wherein therequest to perform the memory access can include: a request-to-own (RTO)signal; or a request-to-share (RTS) signal.
 40. A method for delayingmemory accesses directed to cache lines associated with transactionalexecution, comprising: commencing transactional execution of a block ofinstructions within a thread executing on a processor; and receiving arequest from a requesting thread to perform a memory access involving acache line; wherein if performing the memory access on the cache linewill interfere with the transactional execution and if it is possible todelay the memory access, the method further comprises, performing thememory access at a later time when the memory access will not interferewith the transaction.
 41. The method of claim 40, wherein performing thememory access at a later time when the memory access will not interferewith the transaction involves: storing copy-back information for thecache line to enable the cache line to be copied back to the requestingthread, and performing the memory access and copying the cache line backto the requesting thread at a later time when the memory access will notinterfere with the transactional execution.
 42. The method of claim 40,wherein performing the memory access involves copying the cache lineback to the requesting thread.
 43. The method of claim 40, wherein it ispossible to delay an interfering memory access if a commit operation isin the process of committing updates made during the transactionalexecution to the architectural state of the processor, and if the memoryaccess is directed to a cache line for which a last update made duringthe transactional execution has not yet been committed to thearchitectural state of the processor.
 44. The method of claim 43,wherein a cache line associated with a delayed memory access is copiedback to the requesting thread after the last update to the cache lineduring the transactional execution is committed to the architecturalstate of the processor.
 45. The method of claim 43, wherein a cache lineassociated with a delayed memory access is copied back to the requestingthread after all updates that took place during the transactionalexecution are committed to the architectural state of the processor. 46.The method of claim 43, wherein it is possible to delay an interferingmemory access prior to the commit operation; and wherein if thetransactional execution fails prior to the commit operation, the methodfurther involves copying back cache lines for any interfering memoryaccesses that have been delayed during the transactional execution,wherein the data that is copied back is original cache line data, whichhas not been modified during the transactional execution.
 47. Ancomputer system that facilitates delaying memory accesses directed tocache lines associated with transactional execution, comprising: aprocessor; a memory; a transactional execution mechanism within theprocessor configured to commence transactional execution of a block ofinstructions within a thread executing on a processor; and a requestprocessing mechanism within the processor configured to receive arequest from a requesting thread to perform a memory access involving acache line; wherein if performing the memory access on the cache linewill interfere with the transactional execution and if it is possible todelay the memory access, the request processing mechanism is configuredto perform the memory access at a later time when the memory access willnot interfere with the transaction.